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Abstract 


This technical report describes our experience using the interactive theorem prover 
Athena for proving the correctness of abstract interpretation-based dataflow anal- 
yses. For each analysis, our methodology requires the analysis designer to formally 
specify the property lattice, the transfer functions, and the desired modeling relation 
between the concrete program states and the results computed by the analysis. The 
goal of the correctness proof is to prove that the desired modeling relation holds. 
The proof allows the analysis clients to rely on the modeling relation for their own 
correctness. To reduce the complexity of the proofs, we separate the proof of each 
dataflow analysis into two parts: a generic part, proven once, independent of any 
specific analysis; and several analysis-specific conditions proven in Athena. 


Key words: Dataflow analysis, correctness proofs, interactive 
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1 Introduction 


Modern compilers use a variety of dataflow analyses, whose correctness directly 
affects the correctness of the produced executables. Although the theoretical 
foundations of dataflow analyses are well understood and described in detail 
in popular textbooks [19], many such analyses are presented without a formal 
specification of the properties they compute and without a correctness proof. 
Even when detailed paper-and-pencil correctness proofs are given, they tend 
to be very long and mostly tedious. As a consequence, few people ever read 
and review such proofs, leading to low confidence in them. We do not want to 
underemphasize the importance of such proofs: The first author wrote a large 
paper-and-pencil correctness proof for a pointer and escape analysis [23], and, 
although difficult, that proof was invaluable in understanding (and correcting) 
the analysis design. 

The goal of our research is to use advances in interactive theorem proving 
to express analysis correctness proofs in a machine-checkable manner. Using 
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an interactive theorem prover has two advantages. First, it forces the analysis 
designer to be precise in the description of the analysis and in the specification 
of the properties that the analysis computes. Second, the correctness proof 
is machine-checkable. Unfortunately, the increased precision and machine- 
checkability have the drawback of requiring a significant increase in the proof 
effort. In addition, many machine-checkable proofs are unnatural and hard 
to read. We use the interactive theorem prover Athena [4,2] because it has 
the potential to tackle these problems. Proof readability and writability were 
primary objectives in the design of Athena. The goal was to allow for high- 
level structured proofs written in the same style and at the same level of 
detail as the informal proofs that are given in practice. Athena also achieves 
significant proof automation, both through user-defined tactics and through 
the seamless integration of external cutting-edge automated theorem provers 
(such as Vampire [25] and Spass [26]). 

A dataflow analysis computes an analysis fact for each program point; 
the analysis fact conservatively models each possible program state at that 
point. In our approach, we ask the analysis designer to provide a formal 
specification of the modeling relation, and a correctness proof, i.e., a proof 
that the computed analysis facts satisfy the intended modeling relation. Each 
program optimization that uses the analysis results can rely on the modeling 
relation. Therefore, we decouple the problem of optimization correctness into 
two parts: the correctness of the underlying analysis, and the correctness of 
the program transformation. Our work examines only the analysis correctness. 


Proving the correctness of an analysis is a daunting task. To simplify it, 
1) we focus on the high-level definition of the analysis; and 2) we split the 
correctness proof into several simpler proofs. 

Following classic textbooks [19], we express a dataflow analysis as a fixed- 
point of a set of dataflow equations. Intuitively, the analysis starts with a 
special initial analysis fact for the beginning of each analyzed procedure, and 
next uses the analysis transfer functions to abstractly interpret [8] the program 
statements. The analysis facts belong to a property lattice; in the control flow 
join points, the lattice join operator combines the incoming analysis facts. 
Given a set of monotonic constraints / transfer functions over a lattice with no 
infinite ascending chains, there are well-understood algorithms for computing 
the least fixed-point [19]. We consider these fixed-point solvers correct, and 
do not prove their correctness. Instead, given a set of transfer functions, we 
focus on proving that any set of analysis results (one result for each program 
point) that satisfy the transfer functions also satisfy the intended modeling 
relation associated with the analysis. 

We separate the analysis correctness proof into a generic part (proven 
once, independent of the examined analysis), and three sufficient analysis- 
specific conditions. For each new analysis, the analysis designer needs to 
prove these three conditions in Athena. The generic part of the proof is a 
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proof by induction that uses the analysis-specific conditions in its base case 
and induction step. These conditions require that the analysis fact for the 
beginning of an analyzed procedure models the concrete state(s) at that point, 
and that the abstract interpretation of each instruction preserves the modeling 
relation.’ In general, the analysis-specific conditions involve the execution of 
at most one simple instruction; hence, their proofs are significantly easier than 
the entire correctness proof, and, hopefully, large parts of these proofs can be 
automatic. Still, as the execution of an invoked procedure may involve many 
instructions, some sort of user-supplied frame theorem? is required in the case 
of a call instruction. 

Notice that we study the correctness of the high-level analysis specifica- 
tion and not the correctness of a particular analysis implementation. Still, if 
we have a high-level analysis specification, we can automatically generate an 
implementation that solves the dataflow equations [1,27]. 


Contributions: This technical report makes the following contributions: 


e We present a methodology for doing machine-checkable correctness proofs 
for dataflow analyses. Our methodology reduces the proof effort by focusing 
only on a clear set of high-level analysis-specific conditions. 


¢ We present experience in applying our methodology for proving the cor- 
rectness of three related dataflow analyses in the interactive theorem prover 
Athena. In general, the proof effort was reasonable, and the resulting proofs 
are similar to paper-and-pencil proofs. Our proofs are available online from 
http://www.mit.edu/~salcianu/df-proofs. 


Paper structure: Section 2 introduces a simple language that we use for 
the presentation of our ideas. Section 3 formally defines the forward intra- 
procedural dataflow analyses and their correctness. Section 4 presents the 
example of a constant propagation analysis. Section 5 presents our correctness 
proof methodology. Sections 6 and 7 briefly introduce Athena and describe 
our experience in using it to prove the correctness of three related analyses. 
Finally, Section 8 discusses related work, and Section 9 concludes. 


2 Program Representation and Semantics 


This technical report uses the following notation: S™* is the set of all finite lists 
with elements from the set S; St is similar to S*, but contains only non-empty 
lists. We write e: / for the list obtained by adding the element e at the head 
of the list 1. If f is a function A — B, f |a + )] is the function that behaves 
exactly like f, except that f(a) = b. For each relation R C A x B, we write 


! There is also a third correctness condition that we explain later in the paper. 
2 Essentially, a frame theorem is a reduced procedure specification: e.g., a procedure does 
not change the local variables of its caller. 
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a R b for (a,b) € R; R* denotes the transitive and reflexive closure of R. 
We present our ideas in the context of a simple language with recursive 
procedures and local variables. Figure 1 presents the mathematical objects for 
the program representation and semantics. A program P is a mapping from a 
subset of procedure names to the corresponding procedures. Each procedure 
consists of a list of formal parameters and a list of instructions. Instructions 


have the expected semantics; e.g., “uv := ct” loads the constant ct into the 
local variable v; “if(v == 0) goto a” jumps to the a-th instruction from 
the current procedure, etc. 
P  €-~ Program = {P’'€A-— Proc | AC ProcName, main € A} 
p €  ProcName procedure names 
Proc =  Var* x Instr* 
v € Var local variables (including formal parameters) 
Instr = vii=ct |v, t= vg |v := vu, bop v2 
| if (v == 0) goto a 
| v := call p (vo, U1, «+5 Up—-1) | return v 
bop € Bop = {+,-,*,mod, div, <,<,>,>,==,/A,V} 
a € N addresses inside a procedure 
c € State = Stack Concrete states 
S € Stack = (VState x Lab x Var) Execution stack 
Ve VState = Var—-Z State of local variables 
lb € Lab = ProcName x N Program labels 
ow = (Av.0, (main, 0), vo) Initial program state 


Fig. 1. Program representation and semantics. 


Each instruction has a label lb € Lab = ProcName x N: (p,i) is the label 
of the i-th instruction from the procedure named p. instrAtp (lb) denotes the 
instruction from label /b in program P. For most instructions, control goes 
from label Ib = (p,a) to neat ((p, a)) = (p,a+1). For a jump instruction, 
control can also go to the jump target. pred p (lb) denotes the set of control flow 
predecessors of label /b, i.e., labels of the instructions that may be executed 
right before executing the instruction from label /b. 

The meaning of our programs is given by a small-step operational seman- 
tics, informally called the concrete semantics. Currently, a concrete state 
contains only the execution stack. Each stack frame corresponds to a proce- 
dure activation, and contains 1) the state of the local variables of the pro- 
cedure, 2) the current label inside the procedure, and 3) the caller variable 
that will receive the returned value. The state of the local variables is a total 
function from variables to integers; on procedure entry, parameters are ini- 
tialized with the values of the actual arguments; all other local variables are 
initialized to 0.° All variables have integer values; booleans are encoded as 
integers in a C-like fashion. The auxiliary function pc takes a concrete state 


3 Only variables mentioned in the program can have a non-zero value; hence, the state of 
local variables has a finite representation. 
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c = (V,lb,v,) : Sta, and returns the label of the instruction about to be 
executed, i.e., lb. 

The execution of a program P starts with the first instruction from the 
distinguished procedure main, i.e., instrAtp ((main,0)). An execution of P is 
a (possibly infinite) chain of transitions: c”™! = co ~p cy “+p ... “Pp GP 
CGi41 “ep ,.... The transition ¢; ~»p cj, executes the instruction at label 
pc(c;) in program P, i.e., the instruction instrAtp (pc(c)). The transition 
relation ~+p C State x State is defined by a case analysis of the instruction 
executed in that step. Here is a sample case: 

(V, 1b, vy) : Sta ~p (V[v + ct], neat (1b), v-) + Stair 


where instrAtp (lb) = “v := ct”. He) 


Appendix A presents the complete definition of the transition relation ~*p. 
A state is final if its stack has a single frame and the instruction about to be 
executed is “return v.” The value of v is the result of the program. 


3 Forward Intra-Procedural Dataflow Analyses 


Definition 3.1 A forward intra-procedural dataflow analysis A is a function 
that, for each program P, produces a tuple (Lp, |.Jp, Ag”, Mp, Ap), consisting 
rate 


(i) A property lattice Cp, with a join operator Uc, and an induced ordering 
relation C;, (we ignore the subscript Lp whenever it is obvious from the 
context). 


(ii) A family of monotonic transfer functions |.]p : Labp — Lp — Lp, where 
Labp denotes the set of labels from program P. Intuitively, for each label 
lb from P, [lb]p takes the analysis fact for the program point before label 
lb, and returns the analysis fact for the program point after label /b. 

(iii) An initial analysis fact A’ € Lp for the entry point of each procedure. 

(iv) A modeling relation Mp C State x Lp; c Mp Liff the analysis fact | € Lp 
models the concrete state c. 

(v) A function Ap : Labp — Lp, where Labp is the set of labels from P. 
Ap (Ib) is the analysis fact for the program point right before label /b. Ap 
satisfies the dataflow equations: 


Aint if 1b = (p,0) 


VIb € Labp . Ap (lb) 2 |_| [lb2]P(Ap (Ibz)) otherwise 
lb2€pred p(lb) 


The dataflow equations simply state that for each procedure we start with 
an initial analysis fact for the procedure entry point, and next use the transfer 
functions to propagate this information along the control flow graph; we use LI 
in the control flow join points. Strongly connected components in the control 
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flow graph require fixed-points. The dataflow equations use J, instead of 
equality, to allow aggresive fixed-point approximations. 4 

We are now ready to define the correctness of an analysis. We first intro- 
duce a predicate to identify the reachable program states, the only states the 
analysis cares about: 


Definition 3.2 [Reachable States] reachable p(c) & citi! 4p * c. 


Definition 3.3 [Analysis Correctness] Consider a forward intra-procedural 
analysis A that assigns to each program P the tuple (Lp, [.]p, Ap’, Mp, Ap), 
as required by Def. 3.1. Analysis A is correct iff 


VP € Program. Vc € State. reachable p(c) — c Mp Ap (pc (c)) 


In plain English, for each reachable concrete state c, pc(c) represents the 
program point reached by the program execution (i.e., the label of the in- 
struction about to be executed); the analysis correctness condition requires 
that the analysis result for pc (c), i-e., Ap (pe (c)), models the concrete state 
c, with respect to the intended modeling relation Mp. 


4 Example: Constant Propagation 


Preliminaries: If A is a set, L = Lift(A) is the lattice with the elements T, 
1, lift(a) for any x € A, and the following ordering relation: is smaller 
than any element, any element is smaller than T, and distinct elements of L 
are otherwise incomparable. Formally, 


hOpk & (h=11) Vv (e2=T1) V (a=) 
Up L=h; Lup l=h; lUypl =; otherwise, ly Uz lo = T 


If A is a set, and B is a lattice, F = A — B is a lattice with the following 
element-wise ordering relation and join operator: 


fiCr fo & Vae A. fi(a) Cp fo(a) fi Ur fo = Aa. fi (a) Up fo (a) 


Constant Propagation: Figure 2 presents the specification of the constant 
propagation analysis. The property lattice for the constant propagation anal- 
ysis is M = Varp — Lift(Z), where Var p is the set of all variables from the 
program P. For each label /b, the constant propagation analysis computes a 
function m that maps each local variable to L, T, or lift (x), € Z. The mod- 
eling relation (also presented in Fig. 2), requires that for each local variable v 
that has value V(v) = x in the concrete state, m(v) is either T (that approx- 
imates all values), or lift (x). Therefore, if m(v) = lift (x) and the analysis is 
correct (according to Def. 3.3), we know that in any reachable execution state 


4 E.g., widening [8,9]; one can also imagine fixed-point solvers that jump to T after a 
certain number of iterations failed to reach a fixed point. 
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Analysis Property Lattice: M = Varp — Lift(Z) 


Analysis Modeling Relation: 


c Mp m ¢ AVE VState. 3lb € Lab. Ju, € N. 3Stain € Stack. 


(c = (V, lb, vp) : Stain) A 
(Vu € Varp . (m(v) =T) V (m(v) = lift (V(v))) 


Initial Analysis Fact for Procedure Entry Points: A?’ = Xv. T. 


Transfer Functions: 


instrAt p (Ib) [lb] p(m) 

vot= ct m |v + lift (ct)] 
Vy t= U9 m [vy > m(v2)] 
v := vy bop ve mivre T] 

uv := call p (v9, «5 Up—1) | Av’. T 
otherwise (if and return) m (unchanged) 


Fig. 2. Specification of a simple constant propagation analysis. 


at label 1b, v has value x. A program optimization can use this guarantee to 
safely replace any use of v at label /b with the constant 2. 

The transfer functions map v to “lift (ct)” for a “v := ct” instruction 
and propagate constants across “v,; := U2” copy instructions. The transfer 
functions for binary operations and for calls are very conservative; we discuss 
more precise transfer functions in Section 7. 


5 Analysis Correctness Proof Methodology 


This section presents three analysis-specific conditions. As we prove in Theo- 
rem 5.2, these conditions are sufficient for correctness. 


Condition 1 Upper approximations preserve the modeling relation: 
VP € Program. Vc € State. Vl, ly € Lp. 
reachablep(c) A (ec Mp lk) A (4 Ch) — (c Mp h) 
Condition 2 Initial analysis facts are correct: 
VP © Program. Vc € State. Vp EN. 
reachable p(c) A (pe(c) = (p,0)) + ¢ Mp Ajrt 
The next condition uses the intra-procedural transition relation —»p; —»p is 
similar to the transition relation ~»p except that, in the case of a call instruc- 
tion, —»p relates the program states before and after the call by “skipping” 
over all the instructions from the invoked procedure and its transitive callees. 


° This corresponds to our choice that in the property lattice smaller should mean “more 
precise” and bigger should mean “safer” (the opposite choice is also possible). Here is a 
definition of these terms: according to Mp, an analysis fact | € £p models several concrete 
states. The fewer states 1 models, the more precise and less safe 1 is. 
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Condition 3 Commuting diagram (instructions preserve modeling): 
VP © Program. Vc1, co € State. VIE Lp. 
reachable p(c1) \ (cx Mp 1) A (ce, +p C2) > co Mp [pe (c1)]P(2) 


Definition 5.1 c, —»p Cy. iff one of the following conditions is true: 


(i) The instruction about to be executed in c, is not a call or a return 
instruction, and c, ~+p c2; OR 

(ii) The instruction about to be executed in c; is a call, and cy is the concrete 
state immediately after the return from that call, ie., 


_ * 
Aca, C € State. (c1~~»p ca) A (Ca (#lSt!)” cy) A (co +p €2) A (ler = leal) 
where c~+5 c! = (c~p c') A (le| >k) A (|| > &) 


|c| denotes the height of the stack in state c 


In plain English, c, is the state immediately after call, cp) is the state immedi- 
ately before the return from the invoked procedure, and none of the transitions 
between c, and c return from the invoked procedure, i.e., all transitions from 
Cq to @ keep the stack at least as high as the stack from c,. 


Note: Condition 3 can be further split into simpler parts, by specializing it 
for each kind of instructions. 

The next theorem is our only paper-and-pencil proof and shows that con- 
ditions 1, 2, and 3 are sufficient for the correctness of our analysis: 


Theorem 5.2 If an analysis A satisfies conditions 1, 2, and 8, then A is 
correct. 


Proof. Let’s pick an arbitrary program P, and an arbitrary state c € State, 
such that reachable p (c). We shall prove that c Mp Ap (pc (c)). 
Let pce(c) = (p,a), ie., c is about to execute the a-th instruction from 


the p-th procedure. As c is reachable, there exists an execution c’™ = cy ~+p 
C1 Vp... ~*p Cr = c. Let s be the largest 1,1 <i <k, such that |c;| = |c,|, 
and |c-i1| = |c.| — 1, or 0 if no such 7 exists. In both cases, c, is the concrete 


state right at the beginning of procedure p’s invocation that c is still executing. 

The chain of transitions c, ~+p C.41 ~p ... ~*p Cp contains: 1) transitions 
for the instructions from procedure p, and 2) transitions for the instructions 
from procedures invoked by p. We “skip” over the latter transitions by using 
the intra-procedural transition relation: cs = Cs, -»p Cs, Pp .-. —*P Cs, = Ck- 
Each transition cs, -»p Cs,,, corresponds to either 1) a non-call instruction 
from procedure p or 2) a call from p to a procedure p’, the instructions from 
p’ and its transitive callees, and the return back into p. 

We prove by induction that Vi.0 <i<t — cs, Mp Ap(pc(cs,)), and 
next instantiate 7 with t to prove the final result. 


Base case: i = 0. As c,, = ¢, is the state at the beginning of p, Ap (pc (cs,)) J 
Ag” (see dataflow equations in Definition 3.1). By Cond. 2, c,, Mp Az”. By 
Cond. 1, ¢s, Mp Ap (pe (Cs). 
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Induction step: Suppose cs, Mp Ap(pc(cs,)), and let kh = 
[pc (cs; ) lp (Ap (pe (¢s;))). By Cond. 3, ¢s,,, Mp b. As pc (¢s,) € pred p (pe (¢s,41)), 
by the dataflow equations from Def. 3.1, Ap (pe (Gis) ) —] lk. By Cond. 1, 
€9.., Mp Ap (pe ses) This completes our proof. O 


Additional proofs: This paper is focused on partial correctness. So far, we 
did not discuss the proofs that Lp is really a lattice, nor the proof of ter- 
mination. Usually, Zp is obtained by standard lattice constructors: e.g., the 
product of two lattices, the powerset of a set, etc., that are guaranteed to 
produce a lattice. For termination, we have to prove that Lp does not have 
any infinite ascending chain (usually proven by a finiteness argument), and 
that all transfer functions are monotonic. 


Backward analyses: Our methodology can easily be adapted to handle 
backward analyses too: Cond. 2 will refer to the procedure exit points, and 
Cond. 3 will propagate the modeling relation “backward:” 
VP © Program. Vcy, co € State. Vl € Lp. 
reachable p(c1) A (cg Mp 1) A (c1 p c2) > 1 Mp [pc (cr) ]P() 


6 Brief Description of Athena 


Athena [4,3] is a new interactive theorem proving system for multi-sorted first- 
order logic that has facilities for structured proof representation and proof 
checking, automated theorem proving, and model generation. Athena also 
provides a Scheme-like higher-order functional programming language, and a 
proof abstraction mechanism for expressing arbitrarily complicated inference 
methods in a way that guarantees soundness, akin to the tactics and tacticals 
of LCF-style systems such as HOL [12] and Isabelle [20]. Proof automation 
is achieved in two ways: first, through user-formulated proof methods; and 
second, through the seamless integration of state-of-the-art ATPs such as Vam- 
pire [25] and Spass [26] as primitive black boxes for general reasoning. For 
proof representation and checking, Athena uses a block-structured Fitch-style 
natural deduction calculus with novel syntactic constructs and a formal se- 
mantics based on the abstraction of assumption bases [2]. Fitch-style natural 
deduction [21] is a way of structuring proofs so that they mirror the proofs pre- 
sented by mathematicians in practice; special emphasis is placed on modeling 
hypothetical reasoning and keeping track of the scope of assumptions. 

The assumption base contains the propositions that are known to be valid 
at a specific point in the proof. Each (sub)proof adds the proven proposition 
to the assumption base. To prove propositions of the form P, — P:, Athena 
provides special constructs that add P, to the assumption base during the 
dynamic scope of P,’s proof. A proof consists of either the application of 
primitive inference rules (i.e., modus ponens), or the invocation of an external 
ATP. If the external ATP does not succeed in a certain time bound, we do a 
few steps of the proof, and next try the ATP again on a simpler proposition. 
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Common proofs can be abstracted into user-defined methods. 

Among other applications, Athena has been used to implement parts of 
a proof-emitting optimizing compiler [17] and to verify the core operations 
of a Unix-like file system [5]. [4] contains a list of applications, along with a 
tutorial on Athena’s syntax and semantics. 


7 Experience 


We used Athena to formalize and prove the correctness of three related dataflow 
analyses. For each analysis, we proved the three conditions from Section 5 and 
the monotonicity of the transfer functions. 

The first analysis is the simple constant propagation analysis from Sec- 
tion 4. The second analysis extends constant propagation with constant fold- 
ing: The transfer function for a “v := v, bop v2” statement computes the 
result of the binary operation if the analysis already knows that both operands 
are constants. The third analysis improves over the second one by using a more 
precise transfer function for call statements of the form “uv := call p (...)” 
that maps only v to T (instead of all local variables). The correctness proof 
of the third analysis requires the proof of a frame condition, stating that the 
execution of the transitively invoked procedures do not change the caller’s 
local variables, except for the variable that stores the result of the call. 

The table below presents an overview of the formalization and proof ef- 
fort (including the proofs of all intermediate results, e.g., the frame condition). 
During the proofs for the simple constant propagation, the language formaliza- 
tion went though several debugging and simplification iterations. Therefore, 
it is impossible to separate the time spent on the first two entries of the table 
below. 


Formalization | Proofs Total Human 

[# non-commented, non-empty lines] Effort 
Language + semantics 457 164 621 | 15 days 
Simple ct. propagation 174 262 436 | (together) 
+ constant folding +50 +71 +121 | 3 hours 
+ more precise transfer 44] +4685 4.689 eae 
function for call 


The rest of this section gives a brief overview of our work in Athena. All 
proofs are available online from 


http://www.mit.edu/~salcianu/df-proofs 


Our correctness conditions are universally quantified over all programs. To 
prove them, we pick one unknown program P, formalize the structure of P, 
its semantics, and the analysis for P, and prove (in Athena) the correctness 
conditions instantiated for P; next, we generalize over P. 

We introduce Athena sorts (similar to types in a programming language) 
for the sets from the program representation and semantics. We also intro- 
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duce function symbols; each relation/predicate is modeled as a function with 
boolean values. For each function, we declare its signature and a few axioms. 
The signatures allows Athena to do Hindley-Milner-like sort-inference. 


Language formalization: We formalize the program structure and seman- 
tics only once for all the analyses. We declare the sort VarP for P’s variables 
(i.e., the set Varp), the sort ProcNameP for P’s procedure names, and the sort 
Instr for instructions.° The analyzed program is declared as an (uninter- 
preted) function from procedure names to procedures: 


(domain VarP) # Sort: variables from P. 
(domain ProcNameP) # Sort: procedure names in P. 
(declare main ProcNameP) # Name of the main procedure (element of the sort ProcNameP) 
(datatype Instr # Sort: instructions from P. 

(ldc VarP Num) # Constructors correspond to different 

(copy VarP VarP) # kinds of instructions. 

bad 

(datatype Proc # Sort: procedures; one procedure = list of parameters + 

(proc (List-Of VarP) (List-Of Instr))) # List of instructions. 


(declare P (-> (ProcNameP) Proc)) # The analyzed program. 


The formalization of the operational semantics introduces additional sorts, 
axioms for the transition relation step (i.e., ~+p), and many auxiliary axioms. 
The Athena code closely matches the definitions from Section 2 (except that 
Athena uses prefix notation): 


(datatype StackFrame (stackFrame VState Label VarP)) # VState, Label definitions ommited. 
(datatype State (state (List-Of StackFrame) )) 


#... 
(declare step (-> (State State) Boolean)) # Operational semantics transition relation. 
(define step-axiom-ldc # Aziom: transitions for "v := ct" statements. 


# Identifiers starting with "?" denote variables in the object logic. 
(forall ?vstate ?label ?vr ?tail ?cs2 ?v ?n 
(let ((cs1 (state (Cons (stackFrame ?vstate ?label ?vr) ?tail)))) 
(if (currentInstr csi (ldc ?v ?n)) 
(iff (step cs1 ?cs2) 
(= ?cs2 (state (Cons (stackFrame (updateVS ?vstate ?v ?n) 
(next ?label) 
?vr) 
?tail)) )))))) 


(assert step-axiom-ldc) # Add this axiom to the assumption base. 


Analysis formalization: We introduce a polymorphic sort for lattices of 
the form Lift(S) (that can be instantiated for any set 5S), and a sort for the 
analysis lattice Varp — Lift(Z); for each sort, we define the corresponding 
ordering relations: 


# Sort: polymorphic datatype for lifted domains 
(datatype (Lift S) 
bottomLift (lift S) topLift) 
# Definition of orderLift ommited for brevity. 
# Sort for the analysis lattice. To encode Varp — Lift(Z) in the first-order logic 


® There are several Athena keywords for introducing sorts. The simplest is domain; 
datatype/structure introduce a sort too, but they also introduce function symbols for 
the datatype constructors; a structural induction mechanism; axioms stating that each el- 
ement of the sort is obtained by using a constructor; and, in the case of datatype, axioms 
stating that the domain is freely generated. For non-datatype domains, the user can specify 
a different equality relation. 
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# of Athena, we use a representation similar to a list of association pairs. 
(structure M 

allTop # allTop encodes Av. T 

(updateM M VarP (Lift Num))) # (updateM mv x) encodes m[vt> ax 
# The axioms for updateM (ommited for brevity) state that (lookUpM ?x ?m) returns the 
# first association for ?x in the mapping ?m, or topLift tf no such association exists. 
# Order relation for the analysis lattice. 
(declare orderM (-> (MM) Boolean)) 
(define orderM-axiom 

(forall ?m1 ?m2 
(iff (orderM ?m1 ?m2) 
(forall ?x (orderLift (lookUpM ?x ?m1) 
(lookUpM ?x ?m2)))))) 


The definitions for the modeling relation and the transfer functions closely 
correspond to the definitions from Section 4. The predicate (model c m) 
holds iff c Mp m; similarly, (tf lb m, mz) holds iff [/b]p(m 1) = mz. 


Proofs: We prove the first two correctness conditions automatically, using 
Athena’s interface to Vampire [25]. Cond. 2 is the easiest: Vampire proves 
that Cond. 2 follows from the set of all axioms; for Cond. 1, we had to pass 
only a subset of the axioms (Vampire takes too much time if we give it the 
full set of axioms). Condition 3 requires significantly more effort. The Athena 
definition of Cond. 3 closely follows the definition from Section 5: 
(define commuting-diagram # Condition 3. 
(forall ?cs1 ?cs2 ?m1 ?m2 ?lab 


(if (and wfProg # Analyzed progran is well-formed; e.g., no invalid jumps. 
(reachableState ?csi) # reachable p (?cs1) 


(model ?cs1 ?m1) # ?cs1 Mp ?m1 
(ipStep ?cs1 ?cs2) # ?csl —»p ?cs2 
(pe ?csi ?lab) # pc(?cs1) = ?lab 
(tf ?lab ?m1 ?m2)) # [?lab]p(?m1) = 7m2 


(model ?cs2 ?m2)))) # ?cs2 Mp ?m2 


To prove commuting-diagram, we perform a case analysis on the instruction 
from ?lab, and prove each case as a separate theorem. The modeling rela- 
tion requires a certain condition to hold for each local variable v (see Fig. 2); 
accordingly, most of the proofs do a case analysis on whether v is the vari- 
able being modified by the instruction or not. The proofs are a combination 
of manual and automatic sub-proofs. The entire proof scripts are available 
online. 


8 Related Work 


Compiler correctness has always been an active research area. [13] presents a 
paper-and-pencil correctness proof for an entire Scheme compiler; small parts 
of the proof were later formalized in Isabelle [7]. The compiler examined 
by [13] consists mostly of syntax-directed conversion steps. By comparison, 
we focus on machine-checkable correctness proofs for dataflow analyses. 

The Verifix project [11] uses program checkers to dynamically check the 
correct compilation of a given program. Formal methods can later be used 
to prove the correctness of the program checkers. The Credible Compila- 
tion framework [22,17] allows a compiler optimization to output, in addition 
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to the optimized program, a proof that the optimized program is semanti- 
cally equivalent to the original one. The proof can be checked by a small 
trusted proof checker; if the proof does not check, the compiler can simply ig- 
nore the problematic optimization. The Translation Validation Infrastructure 
(TVI) [18] attempts to accomplish the same goals as Credible Compilation, 
but without any assistance from the compiler. TVI attempts to discover an 
equivalence proof (instead of just checking a proof produced by the compiler). 
When applied to optimization stages of the GNU C Compiler compiling real 
applications, TVI generates many simulation invariants and the custom-built 
theorem prover manages to prove almost, but not all of them.’ A parallel, 
similar project, Translation Validation, succeeded in handling several aggres- 
sive optimizations that do not preserve the loop structure of the program [28]. 

The correct assumption behind the aforementioned four projects is that 
it is much easier to check the correctness of an optimization on a particular 
program than for all programs. Also, these approaches can detect errors in the 
implementation of conceptually correct analyses. Still, we believe that proving 
the correctness of an analysis for all possible programs is very important for 
the high-level design of the analysis, and can be a useful complement for 
translation validation approaches. 

Cobalt [15] is a framework for defining syntax-directed analyses and opti- 
mizations. Cobalt requires the analysis designer to specify an analysis invari- 
ant, and next uses the theorem prover Simplify [10] to prove the correctness 
of the optimizations. However, Cobalt does not deal with classical dataflow 
analyses: It does not allow the definition of analysis property lattices, transfer 
functions, etc. Instead, Cobalt supports analyses expressed as reachability 
conditions on the control flow graph. ® 

Very close to our research is the work from [14] and [6]. [14] presents 
a correctness proof in Isabelle [20] for the Java Bytecode Verifier (that in- 
cludes a dataflow analysis for computing the stack typing at various program 
points); [6] presents a constructive proof in Coq [24] for a dataflow analy- 
sis for JavaCard Bytecode. Both of these papers present work of excellent 
quality, and the complete resulting proofs are available online.® They dif- 
fer from our work in several respects. First, we place a heavier emphasis 
on proof readability. We aim at allowing analysis designers to write read- 
able proofs, structurally similar to the ones they would write on paper, but 
with the advantage of machine-checkability; we invite the interested readers to 


’ E.g., as explained in [18, Section 6], for the case of gcc compiling itself, 3.5% of the 
constraints generated for the common-subexpression-elimination (CSE) optimization are 
not simplified, i.e., automatically proven by the theorem prover. 

8 A forthcoming publication [16] describes Rhodium, a successor of Cobalt that allows the 
definition of dataflow analyses that use a restricted lattice (a powerset of all user-defined 
analysis facts). Our work aims at proving correctness of dataflow analyses that use a wider 
range of lattices. 

° From http://www.doclsf.de/papers/tcs02.html for [14], 
http://www.irisa.fr/lande/pichardie/CarmelCoq/Esop04 for [6]. 
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contrast our proofs (in terms of readability) with the proofs from [14] and [6]. 
Second, Athena allows significant automation that reduces the overall proof 
effort. This is done by using Fitch-style tactics capable of incorporating ar- 
bitrary computation into the proof-search process; and through the seamless 
integration of state-of-the-art automated theorem provers. To the best of our 
knowledge, the official versions of Coq and Isabelle are not interfaced with 
external ATPs yet. Third, we are more focused on the presentation of a clear 
framework for proving the correctness of a broad class of dataflow analyses, 
instead of getting very focused on one specific analysis. 


9 Conclusion 


This technical report presents our experience with dataflow analysis proofs in 
the interactive theorem prover Athena. Our experience indicates that such 
proofs are possible, and that modern automated theorem provers increase the 
level of automation. Still, the state-of-the-art in theorem proving is very far 
from full automation, and significant human effort is required. 
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A Transition Relation for Concrete Semantics 


This section presents the remaining cases from the definition of the operational 
semantics transition relation ~+p: 


(V, lb, vy) : Sta ~p (V[v1 Re V(v2)], next (Ib), vr) + Stait coay 
where instrAtp (Ib) = “vy := v9” PY 


(V, lb, vp) : Stan ~p (V[u > a], next (1b), u,) : Stain 
where instrAtp (lb) = “v := v1 bop v2” [binop] 
@ (bop, V(w1), V (v2), #) 


@ (bop, #1, #2, x) holds iff aw is the result of binary operation bop on x; and x2 


(V, lb, Ur) : Stair ~p (V, Ibo, Ur) + Stait 

where instrAtp (Ib) = “if (vu liz] 
_ _ f (pa) if Viv) =0 

Deke Ua { neat (Ib) if V(v) #0 


(V, 1b, Ur) : Sta ~P (Veallee, (p,0),v) : (V, next (1b) , ur) : Stail 
where instrAtp (lb) = “v := call p (w,...,Up-1)” 


The p"” procedure of P has parameters vj, U;,---, Up_4 [call] 
Veallee = (Av.0) [% > Vv), v4, V(v1),.--, U1 V (ve-1)] 
(V, lb, up) : (Va, iba, Ur2) : Sta ~p (V2 [Ur  V(v)] , lb, ra) : Stail iret] 


where instrAtp (Ib) = “return v” 
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